-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-thread-safe subscriptions #160
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @richardhuaaa and the rest of your teammates on Graphite |
Your org has enabled the Graphite merge queue for merging into mainAdd the label “Queue” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “Hotfix” to add to the merge queue as a hot fix. You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link. |
58c6ad6
to
ee1edb4
Compare
f2c6b04
to
985e774
Compare
985e774
to
1b33be3
Compare
if a client installation subscribes multiple times, those subscriptions are all separate? |
select { | ||
case <-s.ctx.Done(): | ||
return | ||
case new_batch := <-s.dbSubscription: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am a bit uncomfortable that we are passing a slice to a channel. In this simple use case its correct, but slices are mutable and not thread safe. So it makes me not trust this code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you be more specific about the case you are worried about? In general I'm not sure if there's a hard-and-fast rule that all objects passed into a channel must be immutable (although it would be suspect if they were mutated while they were in the channel, which we don't do)
I believe that you say this in the description of the PR, but I just want to confirm. Right now the client |
For each
Yep, that's right. Picking up historical messages from before the stream was requested (without dropping messages or having duplicates) is a bit more complicated, so I'm splitting it off into a separate PR so as not to make this one harder to review. |
0a6d801
to
c7cfaca
Compare
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @richardhuaaa and the rest of your teammates on Graphite |
1 similar comment
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @richardhuaaa and the rest of your teammates on Graphite |
Introduces a basic initial version of client subscriptions. A worker maintains a global database subscription, and pushes updates to relevant client listeners.
There are many pieces coming in later PR's:
#125